The first Web applications were largely server-based with little or no functionality implemented by client-side scripting. Transitions between application states were mainly accomplished with a request and response round-trip over a network between an end-user computing device and a server device. A Web browser executing on the end-user device would send, to the server device, a Hypertext Transfer Protocol (HTTP) request specifying a Web address (e.g., a URL) that identified the next user interface state (e.g., a new Web page). In response, the server device would send, back to the end-user device, a HTTP response including Hypertext Markup Language (HTML) content of the requested user interface state. The Web browser would then update a user interface (e.g., a Web page window) displayed at the end-user computing device based on the received HTML content.
Over time, with the increasing computing power of end-user computing devices and the wide availability of wired and wireless broadband Internet connections, more and more Web application functionality is now being executed by end-user devices. This shift in processing from server to client is facilitated by the ubiquity of Web browser software that supports Internet standards such Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), Extensible Markup Language (XML), and other standards.
As more and more Web application functionality moves from server to client, a whole new set of challenges face developers of Web applications: functionality that was previously only executed by server devices is now being downloaded to and executed by end-user devices in the form of client-side scripting language instructions. Typically, the client-side scripting language is based on an edition of the European Computer Manufacturers Association (ECMA)-262 scripting language standard. The ECMA-262 standard is generally referred to in the industry as “Javascript”. However, particular implementations of the ECMA-262 standard may be referred to by other names such a “Jscript”, “ActionScript”, “ECMAScript”, etc. The portion of a Web application implemented in a client-side scripting language is referred to herein as a “client-side Web application”. A client-side Web application typically is downloaded to and executed by end-user computing devices with the aid of Web browser software executing on the end-user computing devices. A client-side Web application executing on an end-user computing device may communicate over a data network, with the aid of the Web browser, with one or more servers that implement server-side Web application functionality such as, for example, accessing a back-end database.
A particular set of challenges facing developers of client-side Web applications involves implementing client-side Web application functionality that requires use of sensitive information that should not be downloaded to or stored at end-user devices. Such functionality includes, for example, accessing a third-party online service that requires a developer key or other information used by the third-party service to authenticate the developer. For various reasons, developers would prefer to keep such authentication information private to themselves and the third-party and not accessible to end-users of the client-side Web application. In addition to protecting sensitive information, there may be other reasons (e.g., performance) why developers would not want certain client-side Web application functionality executed by end-user devices. Consequently, a need arises for a technique that provides offloading execution of a portion of a client-side Web application to a server.